Mackerelでユーザーのアクセス管理を考える #mackerelio
こんにちわ、札幌のヨシエです。
今回はMackerelを使う際にあまり触れられないユーザー管理をオーガニゼーション構成と合わせて考えた内容を書いてみます。
IAMリソースを変更している最中に、Mackerelにおいてどのようにアクセス権限を整理するべきなのかに気づいたことが発端で、 MackerelのようなSaaSにアクセスするユーザーの権限は初期導入時にルールとして明文化しない限り業務利用に支障をきたすのではと考えております。
具体的な課題
自分は「一つのオーガニゼーションに存在する複数のサービスに対してアクセス権限を付与することが可能か？」という面が気になりました。
AWSのIAMに触れる方はイメージがしやすいと思いますが、具体的に以下のような構成が可能なのか？というところです。
結論
結論としてはサービスやロール単位でのアクセス権限を制限ということは出来ませんでした。
このような要件を満たすためには各サービス毎にオーガニゼーションを分離する必要があると考えております。
理由をつらつらと書きますので、この点で疑問が解消された方はタブを閉じて頂いて問題ありません。
ユーザー種別を振り返る
まずはMackerelには4種類のユーザー種別があります。
通常の運用監視業務で利用する種別は「管理者」、「一般ユーザー」、「閲覧者」がそれぞれのユーザー情報に設定されるものと考えております。
オーナーアカウントは一つのオーガニゼーションに1ユーザーのみであり、コスト面やオーガニゼーション削除が実施できる最高権限を保有する観点からメーリングリストにオーナーアカウントを紐付けることはリスクが有ることを了承いただければと思います。
詳細な付与権限は公式ヘルプを確認していただければと思いますが、実際に運用ユーザーが必要なものは「一般ユーザー」または「閲覧者」のみと思われます。
オーガニゼーションとは？
オーガニゼーションは名称通り組織や団体を指す単位として認識して頂ければ良いと思います。
Mackerelにおいてオーガニゼーションは一つのスペースとして考えられ、
ユーザーはメールアドレスか連携サービスのアカウントを利用してオーガニゼーションへログインします。
このアカウントに対して上述の4種類からそれぞれの権限が付与します。
より具体的にイメージするため、冒頭で記載した図を使ってみてみます。
オーガニゼーションには複数の監視対象が登録されますが複数ホストを個別に監視することは現実味がないので、
複数の監視対象を整理するべくサービス/ロールといった設定を行うことでグルーピングすることが出来ます。
基本的にはこの時点まで対応が終われば監視を開始することが出来ます。
どういう対応が存在するか？
当初の課題に振り返って、「一般ユーザーと閲覧者には「DevIO Sapporoサービス」のリソースを見せたいが、「DevIO Tokyoサービス」のリソースは見せたくない」という例題を課題として進めると回避策としてはオーガニゼーションを分離する形になると存じます。
これは新規オーガニゼーションを作成して、それぞれのユーザーを招待し直すという形です。
オーガニゼーションを再作成することになるので多くの手間が発生することや過去のメトリック情報を破棄する点とAPIキーが変更されるためmackerel-agent監視を行っている場合はAPIキー変更作業が発生しますのでリスクを伴います。
最後に
今回はユーザー管理でどういうことが出来るかという確認のために本記事を書きました。
今回のような場面が生きてくるのはおそらくは複数の開発会社さんが共同対応するような案件と想定しておりますが、厳密なアクセス権限まで行くとこのような形になるかと思います。
関係者に対して閲覧に対する課題がないようであれば、カスタムダッシュボードを作成してそれぞれの担当チーム毎にリソース監視を実施する形が組織としてはスムーズなのかもしれません。
本件で他の回避策がございましたらTwitter等でご教示頂けるととても嬉しいです。
